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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards" , which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://ipr.etsi.org ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by Joint Technical Committee (JTC) Broadcast of the European 
Broadcasting Union (EBU), Comite Europeen de Normalisation ELECtrotechnique (CENELEC) and the European 
Telecommunications Standards Institute (ETSI). 

NOTE 1: The EBU/ETSI JTC Broadcast was established in 1990 to co-ordinate the drafting of standards in the 
specific field of broadcasting and related fields. Since 1995 the JTC Broadcast became a tripartite body 
by including in the Memorandum of Understanding also CENELEC, which is responsible for the 
standardization of radio and television receivers. The EBU is a professional association of broadcasting 
organizations whose work includes the co-ordination of its members' activities in the technical, legal, 
programme-making and programme-exchange domains. The EBU has active members in about 
60 countries in the European broadcasting area; its headquarters is in Geneva. 

European Broadcasting Union 

CH-1218 GRAND SACONNEX (Geneva) 

Switzerland 

Tel: +41 22 717 21 11 

Fax: +4122 717 24 81 

The Eureka Project 147 was established in 1987, with funding from the European Commission, to develop a system for 
the broadcasting of audio and data to fixed, portable or mobile receivers. Their work resulted in the publication of 
European Standard, EN 300 401 [1], for DAJ3 (see note 2) which now has worldwide acceptance. 

NOTE 2: DAB is a registered trademark owned by one of the Eureka Project 147 partners. 

The DAB family of standards is supported by World DMB, an organization with members drawn from broadcasting 
organizations and telecommunication providers together with companies from the professional and consumer 
electronics industry. 
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Scope 



The present document specifies the Filecasting user apphcation which permits the non-linear dehvery of muhimedia 
content using DAB. Whilst the main focus of the present document is the delivery of audio files over a broadcast 
network, it is also applicable to other media formats too, such as video files and documents which may contain a 
mixture of formatted text and graphics, for example in pdf format. 

Filecasting can be used by broadcasters with existing DAB linear audio services to deliver additional content associated 
(but not necessarily directly linked) with these audio services. Equally it can be used to create standalone Filecast 
services. This content could be an entire programme (podcast), additional short-form content relating to a linear radio 
programme, or news, weather or traffic bulletins. 

Whilst Filecasting is defined as a DAB user application, it can equally be carried over Digital Radio Mondiale (DRM), 
ES201980[i.l]. 



References 



References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the 
reference document (including any amendments) applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are necessary for the application of the present document. 

[1] ETSI EN 300 401: "Radio Broadcasting Systems; Digital Audio Broadcasting (DAB) to mobile, 

portable and fixed receivers". 

[2] ETSI EN 301 234: "Digital Audio Broadcasting (DAB); Multimedia Object Transfer (MOT) 

Protocol". 

[3] ETSI TS 101 756: "Digital Audio Broadcasting (DAB); Registered Tables". 

[4] ETSI TS 101 499: "Digital Audio Broadcasting (DAB); MOT SUdeShow; User application 

specification". 

[5] ETSI TS 102 371: "Digital Audio Broadcasting (DAB); Digital Radio Mondiale (DRM); 

Transportation and Binary Encoding Specification for Electronic Programme Guide (EPG)". 

[6] ISO EN 62106: "Specification of the radio data system (RDS) for VHF/FM sound broadcasting in 

the frequency range from 87,5 MHz to 108,0 MHz". 

[7] ISO/IEC 10646: "Information technology - Universal Coded Character Set (UCS)". 

[8] ISO 3 166-2: "Codes for the representation of names of countries and their subdivisions — Part 2: 

Country subdivision code". 

[9] IETF RFC 2616 (section 13): "Hypertext Transfer Protocol - HTTP/1 . 1 ". 

NOTE: Available at http://tools.ietf.org/html/rfc26 16#section- 13 . 

[10] draft-daviel-http-geo-header-01: "Geographic extensions for HTTP transactions". 

NOTE: Available http://geotags.com/geo/draft-daviel-http-geo-header-01.html . 
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2.2 Informative references 



The following referenced documents are not necessary for the application of the present document but they assist the 
user with regard to a particular subject area. 

[i.l] ETSI ES 201 980: "Digital Radio Mondiale (DRM); System Specification". 

[i.2] ETSI TS 102 8 1 8: "Digital Audio Broadcasting (DAB); Digital Radio Mondiale (DRM); XML 

Specification for Electronic Programme Guide (EPG)". 



Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the terms and definitions given in EN 300 401 [1] and the following apply: 

dynamic broadcast information: Broadcast information relating to the media files and basic presentational 
information for receivers that do not support the ability to decode the EPG channel 

dynamic content: media file that contains content that is frequently updated (e.g. "Latest News") 

NOTE: There will typically be several versions of this media file broadcast, and so it is not always essential that a 
receiver downloads the latest version. 

EPG channel: DAB data stream containing service and schedule information that relates to audio services, Filecast 
services or both 

filecast channel: DAB data stream containing the Dynamic Broadcast Information and media files 

filecast service: collection of media files that are all contained within a particular service-brand, whether linked to a 
linear audio channel (e.g. the "BBC Radio 1 On Demand" Filecast Service contains content related to BBC Radio 1), or 
not (e.g. the "Daily Telegraph On Demand") 

media file: file that contains the actual content 

scheduled content: media file that contains a single programme, and is scheduled to be broadcast at some point in the 
future 

NOTE: Typically only one version of this media file will be broadcast. 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in EN 300 401 [1] and the following apply: 

CA Conditional Access 

DAB Digital Audio Broadcasting 

EPG Electronic Programme Guide 

EEC Forward Error Correction 

HE AAC High Efficiency AAC 

HTML Hyper Text Markup Language 

HTTP Hyper Text Transfer Protocol 

IP Internet Protocol 

MOT Multimedia Object Transfer 

MPEG Moving Pictures Expert Group 

PAD Programme Associated Data 

PDF Portable Document Format 

RDS Radio Data System 

URL Uniform Resource Locator 
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Introduction 



A Filecasting application consists of two components: 

1) Media files: The content itself. 

2) Dynamic broadcast information: This provides signalling information that aids a receiver in downloading 
specific media files, as well as basic presentational information. 

When broadcast on a DAB multiplex, the media files and dynamic broadcast information are transported within the 
same data stream, called the "Filecast channel". Additionally more detailed schedule and presentational information 
may be transported within an EPG channel, using the DAB EPG standard [i.2]. However the specification of this 
enhanced schedule and presentational information is out of the scope of the present document. Figure 1 shows an 
example multiplex configuration, where the DAB Multiplex contains multiple audio services, a Filecast service 
transported within PAD, a Filecast Service within a packet mode data sub-channel and an additional EPG Service. 



Filecast Service 1 



Media Files 



Broadcast 
Information 



Fiiecast Service 2 



Media Files 



Broadcast 
Information 



lUlultiplex 



Audio Service 1 
(Sub-channel) 



Audio Service 2 

(Sub-channel) 

Filecast service in 
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Audio Service n 
(Sub-channel) 



DAB EPG 

(sub-channel) 



Filecast service 
(sub-channel) 




or scope. 



Figure 1 



There are two target categories of Filecast receiver: 



1) Basic Filecast Receiver: This receiver is only able to decode the Filecast channel. It uses the basic 
information within the Dynamic Broadcast Information object to allow a user to select content which they 
wish to store. It cannot decode the additional information contained within the EPG channel. Consequently it 
will only be able to present limited information about the individual media files. 

2) Full Filecast Receiver: This receiver can also decode the additional information contained within the EPG 
channel, and provide a richer, enhanced user experience. 

NOTE 1 : The transfer of files is identical for both types of receiver. 

The Filecasting specification allows for two different configurations of Filecasting-related channels on a single 
multiplex. The following configurations are valid: 

1) Filecast channel only, transported within a packet mode data sub-channel. 

2) Filecast channel only, transported within PAD. 

Where a Filecast channel contains content that is linked to an existing audio service on the multiplex, and is not 
transported in that audio channel's PAD capacity, the Filecast channel is signalled as a secondary component of the 
audio channel. 

NOTE 2: It is possible for a single multiplex to contain multiple Filecast channels. 
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5 Filecast channel 

5.1 Transport mechanism 

The Filecast channel may be transported in either a packet mode sub-channel with FEC applied or in the PAD of an 
audio subchannel. 

MOT in Directory Mode [2] shall be used to transport the Filecast channels. The MOT Directory within the Filecast 
channel can be compressed. 

For any carousels containing Filecasting objects, the data rate for MOT transported in packet mode is limited to a 
maximum of 256 kbps. For packet mode transport, the overall size of the subchannel including the Filecast channel is 
limited to a maximum of 384 kbps. 

When using PAD for filecast object delivery it is important for service providers to be able to continue to deliver 
SlideShow and Dynamic Label in a timely manner. If the Filecast channel is transported in PAD a mixture of file 
objects in Directory Mode and other Header mode objects shall be able to be received. Ideally the PAD server will 
intersperse the header mode objects within the larger Filecast objects. 

The service provider should choose a segmentation size for the filecast objects which allow appropriate time granularity 
dependant on the capacity of the PAD channel to ensure timely delivery of other PAD objects. 

5.2 Filecast MOT carousel 

The media files are broadcast as MOT objects within the Filecast channel. They are referenced from the MOT 
Directory. The MOT Directory is also used as a means of transporting the Dynamic Broadcast Information that is 
required by the Basic Filecast receiver. 

The scope of the MOT Directory is set by the service provider, but it is recommended that it includes all media files that 
are currently being broadcast and planned to be broadcast within that MOT carousel for several days into the future. 
This is due to the reason that a Basic Filecast Receiver will only be able to decode and display listings information from 
the MOT Directory, and not the EPG. Providing information within the MOT Directory only on the currently 
transmitted files will restrict the selection choice of media files for users of these receivers. 

The following extensions and restrictions apply for the Filecast channel: 

• The MOT Directory shall be transmitted at a minimum repetition rate of once per 60 seconds. 

• Compression of the MOT Directory is permitted (as defined in the MOT specification [2]). 

• As a minimum, the MOT Directory shall list the file or files currently in the MOT carousel. It may also list 
files that are planned to be broadcast, for a service provider-defined period of time into the future. 

• The directory entries of the MOT Directory shall be sorted in ascending order of the ContentName parameter 
at the service provider side, using the SortedHeaderlnformation parameter (as defined in the MOT 
specification [2]). 

• The MOT Directory shall have a maximum uncompressed size of 16 kbytes (16 384 bytes). 

MOT parameters that are to be applied to individual MOT objects are carried within the MOT header information of 
each directory entry in the MOT Directory. A summary of the MOT parameters for individual objects that apply to the 
Filecast application are given in table 1, and are specified in detail by the following clauses. The MOT parameters 
detailed in the table below will be used to identify the content of the individual objects. 

NOTE: Any parameters that are encountered that are not understood by a given receiver will be ignored. 
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Table 1 : MOT parameters for Filecast application 



Parameter 


Paramete 
rID 


Specified in 


Usage mandatory for service 
provider 


Usage 
mandatory 
for receiver 


Occurrence 


PermitOutdatedVersions 


0x01 


MOT [2] 


No (if the 

DefaultPermitOutdatedVersions 
parameter has been set) 


Yes 


Single 


Expiration 


0x09 


MOT [2] 


No (if a suitable value is set with 
the DefaultExpiration parameter) 


Yes 


Single 


ContentName 


OxOc 


MOT [2] 


Yes 


Yes 


Single 


CompressionType 


0x11 


MOT [2] 


No (but the parameter shall be 
used for all objects on MOT 
transport level) 


Yes 


Single 


UniqueBodyVersion 


OxOd 


MOT [2] 


Yes 


Yes 


Single 


CAInfo 


0x23 


MOT [2] 


No (but the parameter shall be 
used for all objects encrypted on 
MOT level) 


Yes (non CA 

capable 

receivers 

shall discard 

encrypted 

objects) 


Single 


ContentDescription 


0x25 


The present 
document 


Yes 


Yes (for basic 

Filecasting 

receivers) 


Single 


ContentCategory 


0x26 


The present 
document 


No 


Yes (for basic 

Filecasting 

receivers) 


Multiple 


ClickTroughURL 


0x27 


SlideShow [4] 


No 


No 


Single 


AlternativeLocationURL 


0x28 


SlideShow [4] 


No 


No 


Single 


ParentService 


0x29 


The present 
document 


No (but the parameter shall be 
used for all objects that link to an 
audio service on that multiplex) 


Yes (for basic 

Filecasting 

receivers) 


Multiple 


AvailabilityStart 


0x2a 


The present 
document 


No (but the parameter shall be 
used for all media files that are 
listed within the Directory, but 
which are not contained within 
the currently broadcast carousel) 


Yes 


Single 


PresentationPriority 


0x2b 


The present 
document 


No 


Yes 


Single 


MemberOf 


0x2c 


The present 
document 


No 


Yes (yes for 
receivers 
supporting 
DAB EPG) 


Single 


Location 


0x2d 


The present 
document 


No 


No 


Single 



5.2.1 MOT header core 

The ContentType and ContentSubType parameters shall be set according to the MOT specification [2]. 

5.2.2 ContentName 

This mandatory MOT parameter uniquely identifies the object within the MOT carousel The ContentName parameter is 
used as specified in the MOT specification [2]. 

To permit receiver interoperability, the character set for the ContentName of Filecast objects shall be ISO Latin 
Alphabet No 1, see TS 101 756 [3]. The permitted characters are restricted to a subset of this character set as follows: 
the lowercase Latin letters, the digits, the hyphen, the forward slash and the underscore ("a".."z", "0".."9", "-", "/", "_"). 

5.2.3 CompressionType 

The CompressionType parameter is used as specified in the MOT specification [2]. 
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5.2.4 CAInfo 



This parameter is used if conditional access on the MOT level is applied to the MOT data. The CAInfo parameter is 
used as specified in the MOT specification [2] . 

If this parameter is present a non CA-capable device shall discard this MOT object. 

5.2.5 AvailabilityStart 

This is the date and time from which the media file is transmitted on this Filecast channel. 

• If the AvailabilityStart has a value in the future then this parameter indicates that the media file (and updates to 
the media file in the case of dynamic content) is not part of the current carousel. It informs the receiver when 
the next broadcast of a media file will begin, to enable a receiver to tune in to the Filecast channel at the 
appropriate time. 



• 



If the AvailabilityStart has a value in the past or is omitted then it indicates that the media file (and updates to 
the media file in the case of dynamic content) is in the current carousel of media files being broadcast. 



The value of the parameter field is coded using the same format at the Binary EPG date & time parameter, see 
TS 102 371 [5]. 

5.2.6 PresentationPriority 

The use of this Filecast parameter for each MOT object is optional. This MOT parameter carries a presentation priority 
value for this MOT object. This parameter enables the broadcaster to define the presentation ordering of multiple items. 
If this parameter is specified then where multiple items are displayed they shall be listed according to the presentation 
priority, with the highest priority item being the first item in the list. Lower values indicate a higher priority. The value 
of zero shall not be used; "1" has the highest priority. 

If no priority value is given, content ordering is implementation dependent. 

The value of the parameter field is coded as 16-bit unsigned integer. 

5.2.7 MemberOf 

The use of this Filecast parameter for each MOT object is optional. This MOT parameter carries a shortID linking this 
MOT object to the corresponding group element of the group information in an optionally transmitted EPG service. 

The value of the parameter field is coded using the same format as the Binary EPG shortCRID parameter, see 
TS 102 371 [5]. 

5.2.8 ClickThroughURL 

The use of this Filecast parameter for each MOT object is optional. This describes a URL that may be used by a device 
to respond to a user action (e.g. tapping the screen while the content is presented) to show a linked X(HTML) resource 
within a capable application on the device, e.g. an integrated web browser. 

The URL is specified as a string in UTF-8 encoding, up to a maximum of 512 bytes. 

5.2.9 AlternativeLocationURL 

The use of this Filecast parameter for each MOT object is optional . This describes a URL that may be used by the 
device to acquire the content using a HTTP request over an IP connection. This may be specified on a MOT object that 
has slide content within its body data, indicating an alternative means of acquisition. 

It may also be specified on a MOT object listed within the Directory, but which is not contained within the currently 
broadcast carousel. Devices may use an IP connection to download this content. 

The URL is specified as a string in UTF-8 encoding, up to a maximum of 512 bytes. 
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5.2.10 Location 



The use of this Filecast parameter for each MOT object is optional. This parameter enables location-based services to be 
supported. The location parameter is encoded as a latitude/longitude value pair. 

A latitude value is specified as a 24-bit 2's complement integer number, in 1/92 000 degrees between -90,0 degrees 
(south pole) and H-90,0 degrees (north pole) (leading to a granularity of ca. 2,4 m). 

A longitude value is specified as a 24-bit 2's complement integer number, in 1/46 000* degrees between -180,0 degrees 
(west) and H-180,0 degrees (east) (leading to a minimum granularity of ca. 2,4 m). 

A position's longitude value immediately follows the position's latitude value. 

5.2.11 ContentDescription 

The use of this Filecast parameter for each MOT object is mandatory. This MOT parameter contains a description for 
the media file. It has a maximum length of 128 characters or a maximum of 512 bytes. The character set used shall be 
ISO/IEC 10646 [7] (UTF-8 encoding). The ContentDescription is presented to the user for Basic Filecast receivers, and 
is used by those receivers instead of the programme <longName> and <mediumName> elements contained within an 
optional EPG programme entry for that media file. 

5.2.12 ContentCategory 

The use of this Filecast parameter for each MOT object is optional. This MOT parameter contains information about the 
category or categories for this media file. It has a maximum length of 64 characters or a maximum of 256 bytes. The 
character set used shall be ISO/IEC 10646 [7] (UTF-8 encoding). The ContentCategory is used by Basic Filecast 
receivers for categorizing media files. 

This parameter is used on basic filecast receivers, for display and navigation of content based on content category 
information. 

5.2.13 ParentService 

If the media file contains content that is related to one or more audio services, then this parameter indicates the parent 
audio service. 

If the media file does not have a parent service signalled in its MOT parameters the device shall not assume any 
relationship of the content file with a particular service. 

It uses the same encoding scheme as the <contentId> parameter in the DAB EPG Binary specification, see 
TS 102 371 [5]. 

5.2.14 MOT caching parameters 

It is optional but recommended for service providers and receivers to support the MOT parameters Expiration and 
DefaultExpiration in the MOT Directory as detailed in the MOT specification [2]. 

5.3 Recommended signalling for updated and dynamic content 

When the content of an item changes (i.e. the MOT body object is updated, but the ContentName is not changed), the 
UniqueBody Version parameter should be used, as detailed in the MOT specification [2]. 

Where the previous version of the item is still valid until the new item (MOT body) is fully received, the MOT 
parameters PermitOutdatedVersions and DefaultPermitOutdatedVersions should be used to signal that the receiver is 
allowed to use the previous version. 
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5.4 Rebroadcasting media files 



Where the content within a media file is unchanged, and that file is re-broadcast at a later time, the second and 
subsequent broadcasts should be treated as a retransmission. Consequently the header information, body content and 
SegmentSize of the objects should not be changed, and the Transportid should remain the same. 

This will result in a receiver that has partly downloaded the file on the first transmission, and is able to attempt to 
download the file on one of the re-transmissions, only needing to download the missing MOT segments. 

5.5 Supported content types 

Filecast-enabled receivers are only required to support the content types specified below. 

5.5.1 Audio 

The supported audio compression format is MPEG-4 High Efficiency Advanced Audio Coding v2 (HE AAC v2) profile 
(1 024 frame size) carried in a MP4 container file. 

The file extension in the MOT parameter ContentName shall be ".m4a". 

The ContentType and SubType parameters shall be signalled as MPEG4 Audio, as indicated in the DAB Registered 
Tables TS 101 756 [3]. 

5.5.2 Text 

The supported document types are HTML and PDF. 

The file extension in the MOT parameter ContentName shall be ".html" and ".pdf respectively. 

It is permitted for hmtl files to contain hyperlinks (URLs) which can be activated if the receiver has the ability to 
connect to the internet. 

The ContentType and SubType parameters shall be signalled as HTML and PDF as indicated in the DAB Registered 

Table specification (TS 101 756 [3]). 

5.5.3 Video 

The supported audio compression format is MPEG-4 profile carried in a MP4 container file. 

The file extension in the MOT parameter ContentName shall be ".mp4". 

The ContentType and SubType parameters shall be signalled as MPEG4 Video, as indicated in the DAB Registered 
Table specification (TS 101 756 [3]). 



6 Signalling 

6.1 Application type, FIGO/13 

The use of this application shall be indicated by the use of FIGO/13 with the UserApplicationType signalled as 
Filecasting as defined in TS 101 756 [3]. 

6.2 Secondary component signalling 

If the Filecast channel contains media files that are linked to an audio service on the same multiplex and the Filecast 
channel is not transported in the PAD capacity of that audio service, then the Filecast channel will be signalled as a 
secondary service component of that audio service. 
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As a Filecast channel may be a secondary component of multiple audio channels, the receiver shall be able to determine 
which files are linked to a specific audio channel by decoding the MOT Directory within the Filecast channel. 

6.3 Time and date, FIGO/9 and FIG 0/1 

The provision of a correctly broadcast reference time using FIGO/10 and local time offset using FIGO/9 is a mandatory 
requirement of this User Application. For further details on these parameters, see EN 300 401 [1]. 



Receiver functionality 



7.1 General functionality 

A receiver: 

Shall be able to decode packet mode sub-channels including additional FEC. 

Shall be able to decode a compressed MOT Directory. 

Shall, as a minimum, support the decoding of the audio content type, see clause 5.5.1. 

Shall be able to display all the characters from the extended RDS character set, see ISO EN 62106 [6], 
annex E.2. 

Should be able, as a minimum, to simultaneously decode two sub-channels from the same DAB multiplex - 
one audio sub-channel and one packet mode sub-channel with additional FEC. 

7.2 Presentation of the content to the user 

It is recommended that a receiver: 

• Should provide a simple means for listing media files that are linked (using the MOT parameter ParentService) 
to the audio service they are currently listening to. 

• Should provide details on the status of the download of a particular media file, e.g. "xx% complete" and 
"available". 

• Should use the programme information contained within the EPG channel if it is able to decode that 
information, and it is available. If the receiver is not able to decode the EPG channel or the EPG information is 
not available, the receiver should display the dynamic broadcast information as transported in the Filecast 
channel, in lieu of the Filecast EPG data. 

• Should provide a simple means for navigating through listings that are broadcast. 

• Should provide a simple means for navigating content that is stored on the device. 

• Should present the list of media files within a Filecast Service, ordered alphabetically by ContentName. 

• Should allow a user to view all media files group by Filecast Service or category. 

• Should support Programme Groups, if broadcast in the EPG channel, and should provide a simple means for a 
user to record all Programmes within a Programme Group. 

• Should allow the assignment of a user to a particular group/category in order to allow immediate play back of 
filecast content e.g. breaking news. 

• Should support the notification to the user, if filecast content is available matching the Programme Group of 
the linear service. 
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Should provide a means of filtering the list of media files it presents to the user based on whether or not it is 
potentially capable of receiving and decoding those files. It is recommended that files that the receiver is not 
capable of receiving and decoding should either: not be listed, or indicated as unavailable. Types of files that 
may not be listed, or flagged as unavailable are: 

Text and video files when the receiver does not have the required decoders or display capability (plain 
text files can be displayed on multi-line LCD). If the receiver can be connected to another device 
(e.g. tablet, computer) the receiver should provide control settings to allow the user to decide whether 
they wish to store such files. 

Media files that are only available over a bearer (e.g. wifi), when the receiver does not have wifi 
capability. 

Media files that are scrambled, when the receiver has no means of descrambling these files. 



7.3 Downloading content 



If the receiver is battery-powered, then it is recommended that a user is given the option of not downloading media files 
in the background whilst the unit is in standby. 

If a receiver has a scheduling clash, and is unable to decode all of the available content, it should first prioritize the 
downloading of any content where these parameters signal that the receiver should not use any version of the item 
(MOT object) other than the one that is currently being broadcast. Once this has been fully received, then the receiver 
should download any other files that it is able to. 

The receiver shall provide a means of managing download clashes and failed downloads. The means of doing this shall 
be defined by individual manufacturers, but it is recommended that: 

• Where a file is partly downloaded over DAB and there is a re-broadcast of the file at a later date, the 
downloaded MOT bodies should be cached, so that only the missing bodies are required on the next broadcast. 

• Where use of a different connection could resolve the download clash then this alternative connection should 

be used. 

• Where there is a download conflict resolution, the user should be able to set the default behaviour, so that they 
can choose, for example, the behaviour: 

When the receiver is in standby. 

When the user is listening to an audio service that is the parent service of dynamic content, which 
conflicts with the downloading of other media files. 

When the user is listening to an audio service that is not the parent service of dynamic content, which 
conflicts with the downloading of other media files. 

If a receiver has internet connectivity and a media file is signalled as being available for download via the internet 
connection as well as via DAB, the receiver shall support the capability to download the content over the most 
appropriate of these two connections. Typically a receiver may choose one connection over another, if using that 
connection means that the content would be available to the user sooner. 



7.4 File management 



Filecast uses the MOT Directory to announce the content available to the user, and the Filecast receiver application will 
have various means to filter the content and transfer relevant media files for later use by the user. The receiver keeps all 
objects referred to in the most recently received MOT Directory (this allows the broadcaster to continue manipulating 
the files using changes to the MOT Headers). When an object ceases to exist in the most recently received MOT 
Directory, the receiver may move the file to an alternative storage location, depending on user preferences. After 
transfer, the MOT plays no further part in the management of the media files on the device. 

It is recommended that the receiver should provide means for the user to manually delete media files, and for the user to 
set the receiver to automatically purge files once the onboard memory is fully occupied. 
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7.5 



URL Handling 



A ClickThroughURL MOT parameter defines a web page that is shown on the device as a result of user prompting 
(e.g. clicking a button or tapping the screen) when the content is being displayed. This web page will then launch in a 
web browser on the device and be displayed to the user. 

An AlternateLocationURL MOT parameter defines a URL that may be used by devices as an alternative path to acquire 
the content, over an available IP channel, should one exist. 

Both parameters define HTTP URLs that are applicable only to the content they are sent with. 

The following general guidance is given for handling these URLs: 

• Devices shall ignore URLs with a scheme other than http. 

• Devices shall ignore requests for HTTP authentication. 

• Devices should include the HTTP request header User- Agent when using either URL, to assist in returning a 
more appropriate resource for that device. The header value shall not contain any user-identifiable information. 

• Devices shall handle HTTP status codes denoting errors or resource redirections in the expected way, and 
avoid unnecessary interruption to the user experience. It is recommended that the device follows standard best- 
practices when dealing with status codes other than 200 (OK), including limiting the number of redirections 
followed. 

• Devices should follow standard HTTP practices for caching, in order to minimize bandwidth usage 
(RFC 2616 [9]) particularly use of the HTTP headers Expires, Last-Modified and If-Modified-Since. 

• Devices should include their geographical location, if available, to enable the broadcaster to return a more 
appropriate resource. This should take the form of additional parameters in the HTTP request for the resource, 
as per [10]. 

Table 2 



Header Name 


Description 


IVIandatory 


geo. position 


Geographical coordinates as ordered Latitude and Longitude separated 
by a semicolon (";") 


No 


geo. region 


Geographical region, taken from the reserved list in ISO 3166-2 [8] 


No 



7.5.1 AlternativeLocationURL 

When acquiring content using the Alternative Location URL, devices are recommended to include the following HTTP 
headers in their request, indicating the display dimensions and resolution density of the device, to assist in returning a 
more appropriate resource for that device. 

Table 3 



hHeader Name 


Description 


Mandatory 


Display-Height 


Visible device screen height, in pixels 


No (default is 240 pixels) 


Display-Width 


Visible device screen width, in pixels 


No (default is 320 pixels) 


Display-PPI 


Visible device pixel density, in pixels per inch (PPI) 


No (default is 72 PPI) 



Devices are recommended to consider always fetching the content from its Alternate Location URL, if provided, and 
present the resulting content. The broadcaster may choose to send more appropriate content for the device from this 
URL - for example, based on the user agent and other headers of the HTTP request, or on the devices apparent location. 
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7.5.2 ClickThroughURL 



A device without the means to display X(HTML) content shall ignore a ClickThroughURL and not indicate to the user 
that one is available, nor perform any actions on user interaction. 

If the device does have the means to display X(HTML) content, for example by using a web browser, then it should 
switch to this content on user interaction. 

The device is recommended to continue receiving the DAB service in the background, and may or may not decide to 
continue receiving the broadcast audio based on whether there is any audio associated with the content at the URL 
location. The device may choose to use user preference when making this decision. 
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Annex A (informative): 

Filecast example services and experiences 

A.1 Scheduling downloads of specific content 

During the train ride home from work the user, whilst Hstening to a DAB radio linear transmission, browses through a 
list of available downloads. They choose the 'Weekly Sport Review' and the 'Film Review' media files. They arrive 
home after their daily commute and place their DAB handset into the cradle for charging. The device knows what times 
those media files are delivered over the DAB network, and on what channel, so at 02:30 in the morning the device 
wakes up and downloads those files. When the user next turns on the device, it alerts the user. The user then has the 
choice to consume the content at that time or at a later time. All downloads can be accessed from the 'MyDownloads' 
menu of the device. 



A.2 Scheduling downloads of content categories 

Whilst on the underground, the user browses through a list of content categories on their device. They like "films", and 
so choose to download all content related to films. They arrive home after their daily commute and place their DAB 
handset into the cradle for charging. The device downloads the latest schedules from all the Filecast Services 
broadcasting in its coverage area. On one of these schedules the device knows that a media file in the genre category 
"film" will be delivered overnight, so at 02:30 in the morning the device wakes up, tunes to the appropriate channel and 
downloads that media file. When the user next turns on the device, it alerts the user. The user then has the choice to 
consume the content at that time or at a later time. All downloads can be accessed from the 'MyDownloads' menu of the 
device. 



A.3 Download conflicts 

The user has previously chosen to download the 'Weekly Sport Review'. Whilst looking through the list of available 
media files they find a series on 'Extreme Sports'. They choose to download this media file over DAB. The device is 
provided with a list of times when this will be broadcast over DAB. The first available time to download this media file 
clashes with the 'Weekly Sport Review' download. The 'Extreme Sports' media file is broadcast at another time. The 
device chooses to download the media file at the later time. 



A. 4 Part-downloaded 



The user has previously chosen to download the 'Weekly Sport Review'. The device is downloading this media file at 
the scheduled time. Part-way through the download the user wishes to use the radio to listen to a live audio channel on a 
different multiplex. The device can no longer download the media file at the time that it was expecting to. The media 
file is also broadcast at an alternative time. The device caches the partly-downloaded file, and at the alternative time 
switches on and downloads the remainder of the file. Once this has been downloaded, the media file is presented to the 
user to listen to. 



A.5 DAB WiFi radio 



The user accesses the list of media files from a DAB radio that is also connected to the internet. They search through the 
available media files they can download that are linked to their favourite DAB radio station 'Digital 80s'. The list of 
available media files (that they can download over the broadcast channel) is extended to also include media files that 
can be downloaded to the device via its internet connection. 
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A.6 Frequently updated content 



During the day the user chooses to receive the hourly 'News Update' and, assuming the device is within the reception 
area, from then on the device will download the 'News Update' in the background, and offer the latest version to the 
user. 



A.7 Download whilst listening to live radio 

Whilst listening to a DAB radio linear transmission, the device automatically searches for the Filecasting channel 
associated with the radio station the user is listening to. The device finds such a channel, and so it continuously 
downloads and caches the transmitted files. The device downloads an up-to-date version of the "Breaking News" 
service and alerts the user. The user then has the choice to consume the content at that time or at a later point of time. 



A. 8 Accompanying live radio 



Whilst listening to a DAB linear transmission, the device automatically notifies the user that content related to the 
actual live programme is available. The user then has the choice, to consume the content at that time or at a later point 
of time. 



A.9 Location based services 



A radio station for young listeners does a lot of concerts with local bands/musicians the series is called "Band of the 
week". Additionally to some life events with the band of the week they introduce the band with interviews, they 
produce special unplugged versions of songs and other stuff which is also available over the internet for download as 
podcasts. So over the week the radio station can send this content in the Filecasting service and the announcement of the 
live concert could be linked to the location of this concert. So assume the listener is a big fan of the format, he/she can 
see a category "Band of the week" in the Filecast service. After downloading all the content, the listener can play the 
interviews, listen to the unplugged version of the songs and finally hears the concert advertisement. The DAB/D ABh- 
smartphone shows a location icon in the Filecast player and when clicking on it the listener can see a map with the 
location. 

A commercial radio station sells not only linear radio adds but also offers the possibility to include media files 

(e.g. Restaurant advertisement) into the Filecasting content. This media file could be geo located with the location of the 

restaurant. The filecast player in the car could hand over this location to the navigation system. 

Radio is a very "local" medium and a lot of local radio stations offer a regular overview of events in town. These 
recommendations could be placed in the Filcasting service with a geolocation of the POI for this event. 
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